Web Services Connector
Overview
Bizagi presents an integration layer that provides easy configuration for integration with existing applications through diverse alternatives.
Through this integration layer, Processes in Bizagi can directly communicate with external systems to obtain business information or to update it.
The main feature presented by the integration layer is the Web services connector in Bizagi, which allows your processes to invoke external services through standard web protocols (e.g., SOAP).
Note: Other alternatives for B2B integration, such as Bizagi Connectors, are described at Bizagi connectors.
Before You Start
Bizagi has a Proxy configuration option available to connect with external services such as the Web services connector.
When to Use the Web Services Connector?
Consider as an example, a Credit Request Process in which we may need to look up in a Credit Bureau (or any other system) if the applicant is in the Black List, or to verify his or her borrowing capacity.
As shown in the image below, processes may have many integration points where they need to invoke external services:
In Bizagi, configuring this type of integration is done through a generic Web service connector that can connect to standard SOAP Web services or RESTful services, either residing in an internal network location (intranet) or in the cloud (Internet).
How Does It Work?
Invoking external services from Bizagi will allow business information from Process instances to be sent as input to that external service.
In return, the external service's response will be automatically updated in Bizagi (back into the Process data model).
The information exchange between Bizagi and the service, either set in an ESB, in the cloud, or directly as an available system, is done through standard XMLs. In this way, the integration is independent from the platforms or technologies involved, and the programming language used in the service's implementation.
To configure a Web service invocation (either SOAP or RESTful service), Bizagi's Web service connector presents a series of assisted and graphical steps, in which there is no need for programming.
Important: To invoke external services from within Processes in Bizagi, it is recommended to define these integration points as BPMN Service Tasks.
For more information on configuring these integration points for asynchronous execution, refer to Asynchronous Activities.
Note: When the length of string-type attributes returned by a service exceeds the size of the Bizagi attribute where the data is to be stored, Bizagi will truncate the result in order to fit the length.
About the Web Service Connector
Integration points in the Process are defined from the step #6 of the Process Wizard in Bizagi Studio (Define integration interfaces).
In this step, we configure external services invocations through the Web service connector:
Upon selecting which Service task you want to configure the invocation, Bizagi will present its Web service connector for a guided 4-step configuration.
Take into account that the options presented may vary according to the options selected (i.e., the chosen service type: SOAP or RESTful).
Consider that for RESTful services, it is recommended to use Bizagi Connectors instead. This is because Bizagi Connectors support advanced options such as the possibility to include headers or use OAuth as described next.
Standards Supported by the Web Service Connector
The Web service connector is a powerful generic connector that consumes any Web service, be it set in the corporate ESB, in the cloud, or as an external application.
For SOAP Web services, the following are supported:
- SOAP 1.1 compliant Web services.
- SOAP 1.2 compliant Web services.
Note: Consider these additional notes as well:
- When invoking SOAP Web services, it is required to use POST as the Web method.
- When invoking REST services, XML format must be used in the sent and received information.
- WSDL version 1.0 is supported. Its version 2.0 is not supported.
Additional Web services extensions (WS-*) supported:
- WS-Addressing
- WS-Policy
- WS-Trust
- WS-SecureConversation
- WS-Security: Authentication by Username tokens, and by Binary security token (version 1.1 spec).
For authentication through Binary security tokens, message protection (encryption) requires that the service publishes a public key in its WSDL.
Note: The WS connector supports WSDLs that publish multiple methods and multiple ports. This latter option is specified through the Advanced interfaces configuration. The WS connector does not support WSDLs that publish multiple services.
If you need to invoke a SOAP Web service which uses definitions from a standard not listed above (e.g., WS-Discovery), or to consider a requirement not supported by the connector (such as X invocations of a service, say once per each record of a table), then you will need to use either Bizagi Connectors (preferred), or the Component Library feature in Bizagi.
SOAP and RESTful Services Comparison
Consider the following as a starting point to learn about the differences between SOAP and RESTful services.
| SOAP Web Services | RESTful Services | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Concept & Objective | Bound to its strict protocol definition, it is oriented to exposing pieces of application logic as services (operations). | Focused on exposing named resources publicly based on URIs (protocol-independent), optimal for internet applications and mobile access (exposing data). | | Formats | Tightly based on interchange of information via XML. | Leverages use of JSON format which is more light-weight—optimal for internet applications and mobile use. Can use other formats such as XML. | | HTTP Methods (verbs) | Mainly use POST. | Use POST (to create), GET (to retrieve), PUT (to update), DELETE (to delete). Some services extend the updating capabilities by implementing a PATCH method. | | Security | Usually implement WS-Security and further WS-* specifications of its own. TLS/SSL can be applied as well. | Usually rely on OAuth to protect resources. TLS/SSL can go on top as well. |
Advantages & Disadvantages
- SOAP Web Services: Common in enterprise intranets when there is a need for distributing and handling transactions with a higher level of sophistication (e.g., ACID) and enhanced reliability.
- RESTful Services: Oriented to modern applications and technologies. It has better performance and scalability. Clients consuming RESTful services may not be as easy to build, given that RESTful services do not use a descriptor file and their inputs/outputs depend on each service.
Examples
For more information and examples on Web services invocation, refer to: